In most local area networks (LAN)s, there is typically continuous removal and entry of new devices, and networks. Even if the LAN had been secured from any intrusions and attacks from outside, the new devices and networks that connect to the LAN need not be secure and may provide a path-way for security breaches and cyber-attacks. Currently the IEEE 802.11i and the Extensible Authentication Protocol (EAP) methods from the internet engineering task force (IETF) for wireless networks are the two standards that support secure wireless LAN deployments. These when implemented are expected to provide protection from security breaches and cyber-attacks on the secure WLANs that conform to 802.11 group of wireless networks. The two current security methods under 802.11i and EAP for WLAN security typically only implement 802.1X access control with EAP-having transport level security (TLS) referred to as the 802.1X with EAP-TLS protocol for mutual authentication and performing a negotiation phase allowing for the granting of access based on Pre-Shared Keys (PSKs) or successful authentication through IEEE 802.1x exchanges. IEEE 802.11i provides a Robust Security Network (RSN) with two new protocols: the 4-Way Handshake; and the Group Key Handshake. These utilize the authentication services and port access control described in IEEE 802.1X to establish and exchange the appropriate cryptographic keys.
FIG. 1 shows example components and actions (100) of 802.1X with EAP-TLS protocol. A new network or device designated supplicant (101) requests access to the network through the authenticator (102), which is a gateway or hot spot to the secure local area network (SLAN). The authenticator (102) responds to the supplicant (101) with an EAP protocol request to identify itself. The supplicant (101) provides EAP protocol identification response to the authenticator (102) which is passed on to the authentication server (103) which generate the necessary security keys or challenge to be sent to the supplicant (101). The authenticator sends the key using EAP protocol to the supplicant who responds to the challenge which when checked and accepted by the authentication server (103) result in a successful connection between the supplicant and (101) and the SLAN through the authenticator. This process of secure connection using IEEE 802.11i provides for further security as explained based on the interaction between the access point (AP) which is the authenticator 202 and the supplicant station (STA) which is the client (201) using FIG. 2. The current IEEE 802.11i uses a four-way handshake to establish and ensure the secure and authenticated connection. The initial authentication process is carried out either using a pre-shared key (PSK), or following an EAP exchange through 802.1X (which generally requires the presence of an authentication server). This process ensures that the client station (STA) is authenticated with the access point (AP). After the PSK or 802.1X authentication, a shared secret key is generated, called the Pairwise Master Key (PMK). In a pre-shared-key network, the PSK is the PMK. If an 802.1X EAP exchange was carried out, the PMK is derived from the EAP parameters provided by the authentication server. The PMK is used by both the STA and AP to decrypt messages.
FIG. 2 shows an example sequence of actions 200 used to generate an additional secure key, the pair wise transient key (PTK), and also the Group Temporal key used for multicast and broadcast messages to provide further protection for the paired master key (PMK) under the 802.11i process.
A four-way handshake is used to establish the Pairwise Transient Key (PTK). The PTK is generated by concatenating the following attributes: PMK, AP nonce value (ANonce), STA nonce value (SNonce), AP MAC address, and STA MAC address. The product is then put through a pseudo random function.
The actual messages exchanged during the handshake for generation of PTK are depicted in FIG. 2 and explained below. All messages are sent as EAPOL-Key frames:
The AP (202) sends a nonce-value (ANonce) to the STA (201). The client STA (201) now has all the attributes to construct the PTK (215a) in the first step of the process S211.
The STA sends its own nonce-value (SNonce) to the AP together with a Message Integrity Code (MIC), including authentication, which is really a Message Authentication and Integrity Code (MAIC), in the second step of the process S212.
The AP now constructs the PTK (215b) and the GTK using the information received and sends the GTK and a sequence number together with another MIC. This sequence number will be used in the next multicast or broadcast frame, so that the receiving STA can perform basic replay detection in the third step of the process S213.
The STA sends a confirmation to the AP as the fourth step and completing the process S214.